home *** CD-ROM | disk | FTP | other *** search
/ Over 1,000 Windows 95 Programs / Over 1000 Windows 95 Programs (Microforum) (Disc 1).iso / 1245 / readme.txt < prev    next >
Encoding:
Text File  |  1997-04-18  |  5.7 KB  |  108 lines
  1. The sample COBOL program file STOCKCON.CBL and structured programming techniques
  2. --------------------------------------------------------------------------------
  3.  
  4. Lately, not more than two or three weeks ago, Amanda, posted a message in the
  5. newsgroup COMP.LANG.COBOL, crying desperately for help to solve her current
  6. problems with her program. I responded to her posting by email and I got an
  7. email message from her containing fragments of COBOL code with lots of
  8. errors and fragments of program specifications which did not make much sense.
  9.  
  10. So, I have decided to write a sample program, starting from incomplete
  11. code fragments and program specification to create STOCKCON.CBL. Of course,
  12. I had to improvise a little bit to conceptualize a problem that was not
  13. fully explained to me. This was to give her an idea as to how one can
  14. create a parallell between the program specification and the program
  15. implementation by using the structured programming techniques in COBOL
  16. language. Since the COBOL language implementation for screen handling is
  17. highly platform-dependent, I have used the most primitive ISO/ANSI standard
  18. screen handling statements in order to avoid compilation problems on her
  19. specific platform. I have avoided to use the function keys of the keyboard
  20. also. So, there is nothing pretty about data entry, data display or
  21. menu presentations in this sample program. However, I have done my best
  22. to illustrate the structured programming techniques that I have been using
  23. for a long time. One can talk a lot about these techniques, but the best
  24. thing to do is to give an example so that one can see how these techniques
  25. are employed in real life. Thanks to the structured programming techniques
  26. employed, it was possible, for me, to write, compile, link and test this
  27. sample program in half a day's time. Here are the highligts of these
  28. techniques:
  29.  
  30. 1) Never use GO TO.
  31.  
  32. 2) Go as deep in procedure calls as it is necessary. I have never hit the
  33.    compiler stack limits so far. So, you will probably not hit it either.
  34.  
  35. 4) Use meaningful paragraph names. Keep paragraph names as short as
  36.    necessary but not shorter than necessary. So, if necessary, use up
  37.    the maximum lenght of 30 characters when you need to do so.
  38.  
  39. 5) Use meaningful constant/data names as long as necessary, applying the
  40.    same criteria as those applied to paragraph names.
  41.  
  42. 4) Make the COBOL source file as close to simple English language
  43.    as possible so that, only by reading the COBOL source file, you
  44.    can feel like you are reading the program specification in detail.
  45.  
  46. 5) Use COBOL constants (78 level items) with joy when needed. This
  47.    will render the COBOL code more understandable and it will make
  48.    modification of your code almost free of errors. It is
  49.    much easier to change the value of the numeric constant
  50.    from 30 to 45 in the following example of constant declaration
  51.    than hunting for every occurrence of the constant value 30
  52.    in a large source file and change each one to 45.
  53.  
  54.    78 MaximumNumerOfLinesPerPage  Value 30.
  55.  
  56. 6) If your editor and/or platform of development allows it, use a
  57.    Capital letter to form Constant/Data/Paragraph names instead of
  58.    dashes, thus gaining precious name space and still insuring
  59.    legibility as in the example below:
  60.  
  61.    A113-DoMainProcess but not A113-DO-MAIN-PROCESS.
  62.  
  63. 7) Use four digit alphanumeric paragraph prefixes. This will allow
  64.    you to use the same paragraph name several times, when you need
  65.    to do so in your source program, thus rendering the paragraph
  66.    name unique. Examples:
  67.  
  68.    A251-AddDataToFile.
  69.     A252-DisplayScreenMask.
  70.  
  71.    A452-UpdateDataFile.
  72.     A453-DisplayScreenMask.
  73.  
  74.    Since, A252-DisplayScreenMask is called by A251-AddDataToFile,
  75.    why bother trying to say DisplayAddDataToFileScreenMask, running out of
  76.    name space and than force yourself to find a cryptic paragraph name.
  77.    Since hierachical call order makes it evident that A252-DisplayScreenMask
  78.    called by A251-AddDataToFile, it suffices to say DisplayScreenMask
  79.    prefixed by A252. And in its context, it is also evident that, even
  80.    if you use the same paragraph name in A453-DisplayScreenMask, it is
  81.    the screen mask of the procedure of A452-UpdateDataFile. There are
  82.    abondant other examples of similar situations when you code your
  83.    program. So, quickly chose a paragraph prefix and continue with ease
  84.    to code your program in a meaningful way in its context.
  85.  
  86. 8) Use a rectangular, for comments, in front of each division, section
  87.    and paragraph to aerate your code. Blank lines increase the legibility
  88.    of the code when used as in the example program. You can extend the meaning
  89.    of the paragraph name within the preceding rectangle of comments
  90.    line or just repeat it in open seperated form as an English language
  91.    phrase. This much extra work is tolerable and it improves the
  92.    reading of the code if you want to have an exlusive reading session
  93.    without glancing at the formed paragraph names.
  94.  
  95. 9) Pay a lot of attention to error conditions for file input/output,
  96.    for external routine calls, calculation statements, etc. and
  97.    handle them gracefully when possible and let the program exit
  98.    when an abnormal error condition occurs. When you are not sure
  99.    if an error can be handled, exit the program with an abnormal
  100.    end condition rather than doing nothing to handle the error
  101.    condition.
  102.  
  103. 10)Use a separate paragraph name for each fatal error and indicate
  104.    at least its paragraph prefix when you exit the program with
  105.    abnormal end condition. Thus, you can pinpoint exactly where
  106.    the error has occured. If necessary, you may also add extra
  107.    information such as file-status code, etc.
  108.